This module allows the admin to view all types of Orders in various states.
The realized state can be derived from other states. For example below, where realized is the same as PAYMENT was C.O.D OR had as Online Transaction AND was Successful
SELECT id AS orderId FROM ecom_order WHERE paymentMethod=9 OR id in (SELECT order_id from ecom_transaction WHERE success=TRUE);
While there are several details tracked about an order, it will undergo a series of states. Each state is captured in its history. What each state implies is defined below:
Note: Many of these states may not apply, or apply internally to the system. You can choose to map which of these are significant from a notification or action point of view. So your user interaction status can be a sub-set of these. Internally this is the level of detail the system will maintain for each order.
| Status | Meaning |
|---|---|
| REQUESTED | Order was started and has not proceeded since |
| APPROVED | An optional state in a workflow, where before it an be PLACED or IN_PROCESS or REMIND_USER_TO_PROCEED it is in an APPROVED state ready to be processed. An alternative state can be ON_HOLD or one of the CANCELLED states, which signal it was rejected. |
| REMIND USER TO PROCEED | Order required some admin intervention and the admin now wishes to inform the user to proceed. For example, certain aspects of the payment may not be clear at the time of placing the order. So the admin can specify aditional Shipping rates and direct the user to complete payment and complete the order |
| FAILED TRANSACTION COMPLETE | The last transaction attempted by the customer failed to complete due to the user abandoning the process |
| FAILED TRANSACTION ERROR | The last transaction attempted by the customer failed to complete due to some technical failure |
| IN PROCESS | The order is in process |
| PLACED AUTO | The order was placed by the customer successfully |
| PLACED PARTIAL | (Optional) If a project recognizes partial state between a placement that started automatically but due to some intervention or other system fault could not complete |
| PLACED MANUAL | The order was placed successfully, but by an administrator |
| DISPATCHED | The order has been dispatched to the customer |
| DELIVERED | The order has been delivered to the customer |
| RETURNED | The order was returned by the customer |
| CANCELLED USER | The order was cacelled by the customer |
| CANCELLED ADMIN | The order was cancelled by an Admin on the merchant side, irrespective of user getting the order or not. This can be a REJECT in a workflow where for any reason the Admin did not want the order to proceed. |
| CANCELLED SYSTEM | The order was cancelled by the System or Admin |
| CLAIM REFUND | The order has gone into a refund state but not yet been refunded |
| REFUND | The order was refunded |
| DISPUTE | The order is under dispute |
| CLOSED | The order was closed |
| CAPTURED_AUTO | This is an step before {@link #PLACED_AUTO}; where after an online payment some gateways allow you to CAPTURE the payment. This can be followed by a {@link #PLACED_MANUAL} or {@link #PLACED_AUTO} |
| CAPTURED_MANUAL | This is an step before {@link #PLACED_MANUAL}; where after an online payment some gateways allow you to CAPTURE the payment. This can be followed by a {@link #PLACED_MANUAL} or {@link #PLACED_AUTO} |
| ON_HOLD | The Order is stuck, or waiting for approval or some signal to proceed. IN_PROCESS differs from ON_HOLD in the sense that IN_PROCESS there is progress in the natural course. ON_HOLD explicitly states its not in progress. |
| READY | Service based Orders, may need to communicate Ready to deliver State. Pre-Delivery |
| BACK_ORDER | If an order was requested but was still accepted inspite of zero inventory. Then as a Back Order accept to provide it to the customer. |
Some Bulk actions can be performed on orders. While custom actions can be defined, some of the common actions defined are:
| Action Name | Description |
|---|---|
| Unlock All products from Orders | Will dissassociate all products from orders they belong to. this is useful to delete products etc. Note, that for products removed you may not be able to view additional details in the order and it may impact the invoice generation part. One can always re-lock to come back to this state if the product is not deleted permanently). |
| Remove old requested Orders | A way to clean old stagnant orders in REQUESTED status, which are more than 3 weeks. |
| Re Lock unfinished Orders | Opposite of UnLock All Products. This allows to re-associate any unlocked products with the order again, if the products still exist within the system. |
On clicking on the Order Id of an Order in the order report listing, one can open the order details. Within the order details one can find the following information linked to the order:
The shopping cart uses a client side store that synchronizes itself with the server each time an action like Add, Delete etc is performed on it. By default, the synchronization is instant so that we do not commit any wrong information to the customer. For example if a product could not be added to users cart on Server then on the browser also it will report that, to be consistent. However this can be customized, but not recommended. The instant synchronization also allows us to customize logic while customer is adding products to cart. It is also worth mentioning to prevent, users from influencing or hacking the system the Server only relies on the product codes that constitute a cart, it computes the total, discounts etc afresh and does not rely on stale browser cart information that can be tampered with on the interface by hackers.
This depends on the type of a Cart. A Shopping cart is only maintained for an active session on a browser window. If you were to close the window the session is lost with the window and so is the cart. On the other hand a cart like a Wish list (if any), can persist for the browser however for a Guest user we anyway do not have a handle so for a Guest user the list may or may not be available, but for a Registered user carts persist. Additionally, to ensure the customer did not hack their cart when they connect to the server the Cart is refreshed by what was last maintained on the server when they login. This feature cannot be available for Guest users.
The products are maintained within a cart for as long as the Cart is alive, as explained in the previous section. In addition to this, the cart is ONLY cleared if the user made a successful transaction or the user explicitly removed or added to it. The reason for this is simple, that we do not want a person to keep adding the same products to the cart each time they try to make a payment. It is also worth noting that the definition of a successful transaction implies the user came back from the payment gateway after making a successful purchase. In this case the user has no longer use for the products and they are also permanently committed to the user.
On high demand products, it may be possible that certain products are limited in stock. This creates a dilemma if a product should be available two multiple parties interested or committed to one. We call the strategy that handles this scenario, a Lock Strategy. While we can customize a Lock strategy, the default behavior is to commit a product to a user for a maximum of 30 minutes from the time the product was added, during that time as far as the inventory is concerned its less by the quantity the first user added, for rest of the world. After 30 minutes another person can also add the product to their cart. The lock strategy does not remove the product from the first user after 30 minutes either but then it's a race condition between the previous and the person currently in possession of the lock. Locks can get complicated and the default scenario is sufficient, however as mentioned customization is possible but at an extra effort.
One cart results in one order for a session. A Cart *may* result in multiple unsuccessful order attempts that can be captured by the server or ignored (depends on the project). If we want to track abandoned carts, then the server can maintain unsuccessful or REQUESTED orders also.
For an order a person has the option to re-try payment multuple times if they do not succeed. In this case 1 order can result in multiple transactions, if the user opts to Try Again option, on the same order.
Another way understanding the three is:
Once a customer proceeds to payment and initiates a transaction on the Payment Gateway, the following states/steps occur:
Sometimes an e-commerce order may not be processed real time and we may require the customer to login later. The default Payment Link is:
https://<your domain>/<your payment page>?oid=<customer order id>&uid=<customer user id>
If the order id (oid) matches the user id (uid), and the status and nature of the order permits later payment, then the link can be used to request the user to pay via the Link. Again exact mechanics around are custom for the application in concern.
